The present invention relates generally to system and methods for creating software programs. More particularly, the present invention relates to a visual development system and methods for type-safe binding of object events with event handlers of other objects for software programs operative on digital computers.
Before a digital computer may accomplish a desired task, it must receive an appropriate set of instructions. Executed by the computer's microprocessor, these instructions, collectively referred to as a "computer program," direct the operation of the computer. Expectedly, the computer must understand the instructions which it receives before it may undertake the specified activity.
Owing to their digital nature, computers essentially only understand "machine code," i.e., the low-level, minute instructions for performing specific tasks--the sequence of ones and zeros that are interpreted as specific instructions by the computer's microprocessor. Since machine language or machine code is the only language computers actually understand, all other programming languages represent ways of structuring human language so that humans can get computers to perform specific tasks.
While it is possible for humans to compose meaningful programs in machine code, practically all software development today employs one or more of the available programming languages. The most widely used programming languages are the "high-level" languages, such as C or Pascal. These languages allow data structures and algorithms to be expressed in a style of writing which is easily read and understood by fellow programmers.
A program called a "compiler" translates these instructions into the requisite machine language. In the context of this translation, the program written in the high-level language is called the "source code" or source program. The ultimate output of the compiler is an intermediate module or "object module," which includes instructions for execution by a target processor. In the context of Borland's Turbo Pascal and Object Pascal, the intermediate module is a Pascal "unit" (e.g., .TPU file). Although an object module includes code for instructing the operation of a computer, the object module itself is not usually in a form which may be directly executed by a computer. Instead, it must undergo a "linking" operation before the final executable program is created.
Linking may be thought of as the general process of combining or linking together one or more compiled object modules or units to create an executable program. This task usually falls to a program called a "linker." In typical operation, a linker receives, either from the user or from an integrated compiler, a list of modules desired to be included in the link operation. The linker scans the object modules from the object and library files specified. After resolving interconnecting references as needed, the linker constructs an executable image by organizing the object code from the modules of the program in a format understood by the operating system program loader. The end result of linking is executable code (typically an .EXE file) which, after testing and quality assurance, is passed to the user with appropriate installation and usage instructions.
Recently, "visual" development environments, such as Borland's Delphi.TM., Microsoft.RTM. Visual Basic, and Powersoft's PowerBuilder.TM., are rapidly becoming preferred development tools for quickly creating production applications. Such environments are characterized by an integrated development environment (IDE) providing a form painter, a property getter/setter manager ("inspector"), a project manager, a tool palette (with objects which the user can drag and drop on forms), an editor, a compiler, and a linker. In general operation, the user "paints" objects on one or more forms, using the form painter. Attributes and properties of the objects on the forms can be modified using the property manager or inspector. In conjunction with this operation, the user attaches or associates program code with particular objects on screen (e.g., button object); the editor is used to edit program code which has been attached to particular objects.
At various points during this development process, the user "compiles" the project into a program which is executable on a target platform. For Microsoft Visual Basic and Powersoft PowerBuilder, programs are "pseudo-compiled" into p-code ("pseudo" codes) modules. Each p-code module comprises byte codes which, for execution of the program, are interpreted at runtime by a runtime interpreter. Runtime interpreters themselves are usually large programs (e.g., VBRUNxx.DLL for Visual Basic) which must be distributed with the programs in order for them to run. In the instance of Delphi, on the other hand, programs are compiled and linked into true machine code, thus yielding standalone executable programs; no runtime interpreter is needed.
In the task of visually creating computer programs, a problem exists with associating code or "action" with events that occur in the system. This corresponds, for example, to the action of clicking a screen button (e.g., in Microsoft Visual Basic) and having certain program code execute as a result of that action. Although there exists a number of ways of achieving such an association, prior art approaches to creating such an association have marked limitations.
One approach to addressing the problem has been to use "subclassing." In existing class libraries (e.g., Microsoft Foundation Classes or Borland ObjectWindows Library), if one wanted to change the behavior that happens when a button is clicked in a program, one would create a "subclass" of that button and modify its respective "click" method (e.g., C++ virtual method) to implement the new behavior (i.e., user code). This approach is problematic in itself, however. Most notably, the approach leads to an unwanted proliferation of components in the system. For instance, it would be a ridiculous approach to have a separate button for each and every type of action one could possibly think of for a button. The subclassing approach of modifying behavior leaves a lot to be desired.
Another approach is to provide some form of delegation. "Delegation" is the ability to "delegate" control to somewhere. In other words, an event occurs at one object which in turn "delegates" responsibility for acting on that event to somewhere else. When modification of object behavior is required, therefore, control can be delegated elsewhere. In Microsoft Visual Basic, a limited form of "delegation" is available in the sense that a new button is not created in order to modify the behavior of a button. In Visual Basic, for instance, one can associate code with an event in the visual environment. The user cannot programmatically (i.e., through code), however, change what code gets executed upon occurrence of a particular event, such as the clicking of a particular button. Instead, Visual Basic provides an internal dispatcher so that an association created in the visual environment between an event and program code (which is to execute in response to that event) is carried out at runtime execution of the program. Specifically, the runtime interpreter of Visual Basic "behind the scenes" transfers control to the entry point of the relevant event handler, upon occurrence of the event. This type of "delegation" is pre-wired by the design environment and is not reflected in the language, as a language construct. The problem with this approach, of course, is that the user programmer cannot "get at" the internal code which is hard wired into the Visual Basic interpreter. One cannot modify programmatically where control gets delegated to (i.e., what event handler is invoked when the button is clicked). Since users of such products are unable to programmatically control aspects of the program which correspond to actions undertaken in the visual environment, runtime modification of where control gets delegated to is not possible.
The disadvantages of the prior art approaches can be summarized as follows. The subclassing approach to modifying behavior (i.e., the non-delegation model) entails the substantial disadvantage of class proliferation--an approach which itself leads to problems of bookkeeping (instead of solving the task at hand). The disadvantage with Visual Basic (and other environments which adopt that approach) is that delegation is not a natural extension of whatever language is provided in the environment. Therefore, the actual delegation is hidden from the programmer in a manner which hinders the programmer's ability to switch back and forth between source code and visual environment view of the program under development.
What is needed, therefore, is a development system with methods which allow anything that can be done visually (e.g., clicking a button and having code execute) to also be done programmatically (i.e., through the programming language). Specifically, delegation is provided as a fundamental feature of the programming language for the environment. Such a system would allow the programmer to treat program code attached to an object as a property of that object. In this fashion, such an environment can provide visual "two-way" tools which are built on top of a programmatic mapping--that is, the tools reflect what the user himself or herself could do in the code.